DevSecOps_04_공급망 보안과 SCA 메커니즘

현대 소프트웨어 개발에서 "코드를 처음부터 끝까지 다 짜는" 경우는 거의 없다. 대부분의 기능은 외부 라이브러리나 프레임워크에 의존한다. 내가 작성한 비즈니스 로직이 안전하더라도, 가져다 쓴 라이브러리에 취약점이 있다면 내 서비스도 위험해진다. 이것이 공급망 보안(Supply Chain Security)이 대두된 배경이다. SCA(Software Composition Analysis) 도구가 이러한 외부 위협을 어떻게 식별하는지 알아본다.

1. 직접 의존성과 전이적 의존성

SCA의 핵심은 내가 명시한 라이브러리뿐만 아니라, 그 라이브러리가 사용하는 또 다른 라이브러리까지 추적하는 것이다.

• 직접 의존성(Direct Dependency): package.json이나 requirements.txt에 명시된 패키지.
• 전이적 의존성(Transitive Dependency): A가 B를 쓰고, B가 C를 쓸 때, A는 C에 전이적으로 의존한다.

Log4Shell 사태가 치명적이었던 이유는, 개발자가 직접 Log4j를 쓰지 않았더라도, 사용 중인 수많은 프레임워크가 내부적으로 이를 참조하고 있었기 때문이다. SCA 도구는 패키지 매니저의 락 파일(package-lock.json, go.sum 등)을 파싱하여 이 거대한 의존성 그래프(Dependency Graph)를 그려내고 취약점을 매핑한다.

2. SBOM: 소프트웨어의 명세서

SCA의 결과물인 SBOM(Software Bill of Materials)은 소프트웨어를 구성하는 모든 컴포넌트의 목록이다. 식품의 "원재료명 및 함량" 표기와 같다.

SBOM이 있으면 새로운 취약점(Zero-day)이 발견되었을 때, 우리 서비스가 영향을 받는지 즉시 조회(Query)가 가능하다. SBOM이 없다면 모든 코드를 다시 뒤져야 한다.

3. 오탐과 우선순위 관리

SCA 도구는 수많은 취약점 경고를 쏟아낸다. 이를 모두 수정하는 것은 현실적으로 불가능하다. 따라서 "도달 가능성(Reachability)" 분석이 중요하다.

• 취약한 라이브러리 버전 v1.2.3을 사용 중이다. (경고 발생)
• 하지만 우리 코드는 그 라이브러리에서 취약한 함수 vuln_func()을 호출하지 않는다. (실제 위험 없음)

단순한 버전 매칭을 넘어, 실제 호출 그래프(Call Graph)를 분석해 "실제로 실행될 수 있는 위험"만 필터링하는 것이 SCA 기술의 고도화 방향이다.